perf(devtools): stop the panel freezing on caches with thousands of queries - #11150

Render the query pane through a new windowed VirtualList so only the rows
in (and near) the scroll viewport are mounted. Because each QueryRow owns
five query-cache subscriptions, windowing bounds both the DOM node count
and the module-level subscription map that the global cache handler walks
on every event, instead of scaling with the number of cached queries.

VirtualList seeds its viewport from a bounded default (never the item
count), resolves ResizeObserver from the element's own document for
Picture-in-Picture, clamps the scroll offset so a shrinking list never
blanks the viewport, and always keeps the selected row mounted. Row
offsets are arithmetic given the fixed row height derived from
--tsqd-font-size.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 639057ed-0ed9-4329-8008-71458714184f

Render the mutation pane through the same windowed VirtualList as the
query pane, bounding mounted MutationRow components and their mutation-
cache subscriptions to the visible window.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 639057ed-0ed9-4329-8008-71458714184f

Each MutationRow previously resolved its own mutation by scanning the
whole mutation cache with getAll().find() in three subscriptions, so a
mutation-cache event cost O(rows x cache size). Read the row's own stable
mutation instance directly instead; the subscription still fires on cache
changes but the read is O(1).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 639057ed-0ed9-4329-8008-71458714184f

Add tests for the windowed list: bounded row count for large caches,
a bounded initial render even when no resize measurement is delivered,
spacer sizing to the full list height, scroll-driven row recycling,
filter-shrink after deep scroll not blanking the viewport, view remount
re-initialization, the selected row staying mounted exactly once when
scrolled out of range, the query-key title attribute, and a mutation row
rendered from its own state.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 639057ed-0ed9-4329-8008-71458714184f

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 639057ed-0ed9-4329-8008-71458714184f

The subscriber registries for the query and mutation caches are shared by
every devtools instance on the page, but a panel's teardown cleared them
entirely rather than removing only its own entries. With two panels mounted
at once - during the picture-in-picture transition, or when the standalone
panel is used alongside the floating one - tearing one down unsubscribed the
other, leaving its list, status counts and details pane frozen.

Each subscription already deletes its own entry on disposal, so the
registry-wide clear was redundant as well as harmful.

The virtualized lists rebuilt every mounted row on each scroll and each cache
event. The window is recomputed into freshly allocated row wrappers, so the
keyed list's item signal always notified, and because the row was rendered by
calling the row renderer inside a child position that read that signal, every
notification tore down and reconstructed the row - its DOM, its styles and its
five cache subscriptions.

Rows now receive an accessor and read the item through a prop, so a row is
built once and updated in place. This is the shape the lists used before they
were virtualized.

Each status badge backed its count with an independent cache subscription, and
every one of those subscriptions walked the whole cache and allocated a
full-size array on each cache event - five passes for queries, four for
mutations. Each set of counts now comes from one pass.

The individual counts are exposed as memos so a badge still only re-renders
when its own count changes, as it did when each count had its own
equality-checked signal. The mutation tally carries a bucket for the gray
status that no badge displays, because an idle mutation resolves to it and the
tally has to stay exhaustive.

While a query was selected, the details pane derived seven values through
seven separate subscriptions, and each located the query by scanning the whole
cache and allocating a full-size array on every cache event. The cache is keyed
by query hash, so each of those lookups is now a direct retrieval - the same
correction the query rows already had.

The mutation cache has no keyed access, so the mutation pane keeps its scan but
derives all three of its values from one shared lookup rather than three. That
lookup's equality check stays disabled: a mutation's object identity does not
change across status transitions, so the pane would otherwise freeze on its
first rendered state.

A mutation-cache event scheduled every subscriber on its own microtask, so
each signal write triggered an independent downstream update. The fan-out now
runs inside a single microtask with the writes batched together, so one event
produces one update.

The batch has to sit inside the microtask rather than around the loop: a batch
around the loop would exit before any deferred setter ran. Iterating the
registry inside the tick also means subscriptions disposed in the meantime are
skipped rather than written to after disposal.

…omponent

`stylesFactory` builds around sixty CSS-in-JS templates, and twelve components
in the panel plus six in the JSON explorer each called it from inside their own
per-instance memo. Two of those components are the query and mutation rows, and
the explorer is recursive - one instance per node of the rendered object - so
with a large cache the whole stylesheet was recompiled for every row the
virtualized list mounted and for every node the details pane expanded.

The compiled result depends only on the theme and the `css` instance, so it is
now memoized on both. Memoizing on the `css` instance only helps if that
instance is stable, and it was not: every call site built its own with
`css.bind({ target })`, which returns a new function object each call, so a
cache keyed on it would never hit for a panel mounted in a shadow root - which
is how the devtools are normally embedded. The bound function is therefore
cached per shadow root as well.

Both helpers live in `utils.tsx` so that the panel and the explorer, which each
keep their own stylesheet, can share them.

…e unchanged

The list of queries to render was rebuilt into a fresh array on every cache
event. Most events leave both the membership and the order of that list
untouched - a query's data changing, or a fetch settling, cannot reorder
anything, and half of all events are observer notifications - but the new array
was still a new value, so every downstream consumer recomputed and the
virtualizer rediffed.

The memo now holds the previous array whenever the recomputed one contains the
same queries in the same order, so consumers only rerun when the list has
genuinely changed. The sorted array is always freshly allocated before it is
sorted in place, so a retained array is never mutated afterwards.

Two devtools subscribers - the query count and the status tallies - inspect
every query in the cache each time they run, and they ran once per cache event.
A stream of arriving, updating and expiring queries therefore cost a full-cache
pass per event, and each `setQueryData` emits two events. With several thousand
queries that is enough to stall the page for as long as the panel is open.

These two now coalesce. A subscriber that has been idle for a window runs
immediately, so an isolated change is never delayed; events arriving inside a
window fold into a single trailing pass. Per-row subscribers are already
filtered to one query and are unchanged.

Three details of the window matter. It is measured in time rather than
microtasks, because cache events usually arrive in separate tasks - one per
network response - and a microtask window would close between every pair of
them, coalescing nothing. It is stamped when a pass finishes rather than when
it starts, because a start-to-start window shorter than the pass leaves every
event outside it, so nothing coalesces and the passes run back to back. And it
widens to a multiple of the last pass, which bounds the share of the main
thread the subscriber can take however large the cache becomes.

A pass being in flight is tracked separately from a trailing pass being armed.
An event raised from inside a pass has nothing in flight that can reflect it,
so it is remembered and a trailing pass is armed once the pass unwinds, rather
than being folded into a pass that has already read the cache.

The clock is `performance.now()`; `Date.now()` can step backwards on a clock
correction, which would hold a subscriber closed for the size of the step.

At eight thousand queries with a mixed stream of arrivals, updates and removals
these three changes together take the panel from blocking around 90% of wall
clock, with a longest block of 142 ms, to blocking under half with a longest
block of around 32 ms.

…on test

Collapses the per-fix changesets into the single entry this pull request should
produce, matching how the devtools changelog is written elsewhere - one entry
per pull request rather than one per commit. The entry also records that the
coalescing window widens with the measured cost of a pass, which is the one
user-visible timing change in this work.

Also replaces an assertion in the row-recycling test that reduced to
`reused.length === reused.length` and so passed whatever the virtualizer did.
The scroll in that test advances the window by exactly one row, so the exact
count is assertable. Drops an `overscan` prop on the internal virtual list that
no call site ever set.